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Textual Conventions for Additional High Capacity Data Types 
Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 


Copyright Notice 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


Abstract 


This memo specifies new textual conventions for additional high 
capacity data types, intended for SNMP implementations which already 
support the Counter64 data type. The definitions contained in this 
document represent a short term solution which may be deprecated in 
the future. 
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1. The SNMP Management Framework 


The SNMP Management Framework presently consists of five major 
components: 


(0) An overall architecture, described in RFC 2571 [RFC2571]. 


fe) Mechanisms for describing and naming objects and events for the 
purpose of management. The first version of this Structure of 
Management Information (SMI) is called SMIv1 and described in STD 
16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 
[RFC1215]. The second version, called SMIv2, is described in STD 
58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, 
RFC 2580 [RFC2580]. 


(0) Message protocols for transferring management information. The 
first version of the SNMP message protocol is called SNMPv1 and 
described in STD 15, RFC 1157 [RFC1157]. A second version of the 
SNMP message protocol, which is not an Internet standards track 
protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] 
and RFC 1906 [RFC1906]. The third version of the message 
protocol is called SNMPv3 and described in RFC 1906 [RFC1906], 
RFC 2572 [RFC2572] and RFC 2574 [RFC2574]. 


fe) Protocol operations for accessing management information. The 
first set of protocol operations and associated PDU formats is 
described in STD 15, RFC 1157 [RFC1157]. A second set of 
protocol operations and associated PDU formats is described in 
RFC 1905 [RFC1905]. 


(0) A set of fundamental applications described in RFC 2573 [RFC2573] 
and the view-based access control mechanism described in RFC 2575 
[RFC2575]. 


A more detailed introduction to the current SNMP Management Framework 
can be found in RFC 2570 [RFC2570]. 


Managed objects are accessed via a virtual information store, termed 
the Management Information Base or MIB. Objects in the MIB are 
defined using the mechanisms defined in the SMI. 


This memo specifies a MIB module that is compliant to the SMIv2. The 
textual conventions defined in this MIB module cannot be translated 
to SMIv1 since the Counter64 type does not exist in SMIv1. 
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Overview 


The Structure of Management Information [RFC2578] does not explicitly 
address the question of how to represent integer objects other than 
counters that would require up to 64 bits to provide the necessary 
range and precision. There are MIBs in progress targeted for the 
standards track, which need such data types. This memo specifies a 
short term solution, using textual conventions, to meet these needs. 


1. Short Term and Long Term Objectives 


There is an immediate need to provide a Gauge64 data type, similar in 
semantics to the Gauge32 data type, in order to support common data 
representations such as: 


- a snapshot of a Counter64 at a given moment, e.g., history ring 
buffer 


- the difference between two Counter64 values 


There is also an immediate need for a 64-bit zero-based counter type, 
similar in semantics to the ZeroBasedCounter32 TC defined in the 
RMON-2 MIB [RFC2021]. 


Both of these textual conventions should use a base type of Gauge6é4 
or Unsigned64, but such a base type is not available. Until sucha 
base type is defined and deployed, these temporary textual 
conventions (which use a base type of Counter64) will be used in MIBs 
which require unsigned 64-bit data types. 


In order to be backward compatible with existing implementations of 
Counter64, the ASN.1 encoding of unsigned 64-bit data types must be 
identical to the encoding of Counter64 objects, i.e., identified by 
the [APPLICATION 6] ASN.1 tag. 


Note that the textual conventions defined in this document represent 
a limited and short-term solution to the problem. These textual 
conventions may be deprecated as a long term solution is defined and 
deployed to replace them. A MIB object which uses either of these 
textual conventions may also eventually have to be deprecated. 


-2. Limitations of the Textual Convention Approach 


New unsigned data types with textual conventions based on the 
Counter64 tag, instead of a new (or other existing) ASN.1 tag have 
some limitations: 
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- The MAX-ACCESS of the TC must be read-only, because the MAX-ACCESS 
of the underlying Counter64 type is read-only. 


- No sub-range can be specified on the TC-derived types, because 
sub-ranges are not allowed on Counter64 objects. 


- No DEFVAL clause can be specified for the TC-derived types, 
because DEFVALS are not allowed on Counter64 objects. 


- The TC-derived types cannot be used in an INDEX clause, because 
there is no INDEX clause mapping defined for objects of type 
Counter64. 


3. New Textual Conventions 


The following textual conventions are defined to support unsigned 
64-bit data types. 


3.1. CounterBasedGauge64 
This textual convention defines a 64-bit gauge, but defined with 


Counter64 syntax, since no Gauge64 or Unsigned64 base type is 
available in SMIv2. 


This TC is used for storing the difference between two Counter64 
values, or simply storing a snapshot of a Counter64 value at a given 
moment in time. 


3.2. ZeroBasedCounter64 


This textual convention defines a 64-bit counter with an initial 
value of zero, instead of an arbitrary initial value. 


This TC is used for counter objects in tables which are instantiated 
by management application action. 


4. Definitions 
HCNUM-TC DEFINITIONS ::= BEGIN 
IMPORTS 
MODULE-IDENTITY, mib-2, Counter64 
FROM SNMPv2-SMI 
TEXTUAL-—CONVENTION 
FROM SNMPv2-TC; 


hcnumTC MODULE-IDENTITY 
LAST-UPDATED "2000060800002" 
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ORGANIZATION "IETF OPS Area" 

CONTACT-INFO 
" E-mail: mibs@ops.ietf.org 

Subscribe: majordomo@psg.com 


with msg body: subscribe mibs 


Andy Bierman 

Cisco Systems Inc. 

170 West Tasman Drive 
San Jose, CA 95134 USA 
+1 408-527-3711 
abierman@cisco.com 


Keith McCloghrie 

Cisco Systems Inc. 

170 West Tasman Drive 
San Jose, CA 95134 USA 
+1 408-526-5260 
kzm@cisco.com 


Randy Presuhn 
BMC Software, Inc. 
Office 1-3141 
2141 North First Street 
San Jose, California 95131 USA 
+1 408 546-1006 
rpresuhn@bmc.com" 
DESCRIPTION 
"A MIB module containing textual conventions 
for high capacity data types. This module 
addresses an immediate need for data types not directly 
supported in the SMIv2. This short-term solution 
is meant to be deprecated as a long-term solution 
is deployed." 
REVISION "2000060800002" 
DESCRIPTION 
"Initial Version of the High Capacity Numbers 
MIB module, published as RFC 2856." 
::= { mib-2 78 } 


CounterBasedGauge64 ::= TEXTUAL-—CONVENTION 
STATUS current 
DESCRIPTION 


"The CounterBasedGauge6é4 type represents a non-negative 
integer, which may increase or decrease, but shall never 


2000 


exceed a maximum value, nor fall below a minimum value. The 


maximum value can not be greater than 2%64-1 
(18446744073709551615 decimal), and the minimum value can 
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not be smaller than 0. The value of a CounterBasedGauge6é4 
has its maximum value whenever the information being modeled 
is greater than or equal to its maximum value, and has its 
minimum value whenever the information being modeled is 
smaller than or equal to its minimum value. If the 
information being modeled subsequently decreases below 
(increases above) the maximum (minimum) value, the 
CounterBasedGauge64 also decreases (increases). 


Note that this TC is not strictly supported in SMIv2, 
because the ’always increasing’ and ’counter wrap’ semantics 
associated with the Counter64 base type are not preserved. 
It is possible that management applications which rely 
solely upon the (Counter64) ASN.1 tag to determine object 
semantics will mistakenly operate upon objects of this type 
as they would for Counter64 objects. 


This textual convention represents a limited and short-term 
solution, and may be deprecated as a long term solution is 
defined and deployed to replace it." 


SYNTAX Counter64 


ZeroBasedCounter64 ::= TEXTUAL—CONVENTION 
STATUS current 
DESCRIPTION 


Bierman, 


"This TC describes an object which counts events with the 
following semantics: objects of this type will be set to 
zero(0) on creation and will thereafter count appropriate 
events, wrapping back to zero(0) when the value 2%64 is 
reached. 


Provided that an application discovers the new object within 
the minimum time to wrap it can use the initial value as a 
delta since it last polled the table of which this object is 
part. It is important for a management station to be aware 
of this minimum time and the actual time between polls, and 
to discard data if the actual time is too long or there is 
no defined minimum time. 


Typically this TC is used in tables where the INDEX space is 
constantly changing and/or the TimeFilter mechanism is in 
use. 


Note that this textual convention does not retain all the 
semantics of the Counter64 base type. Specifically, a 
Counter64 has an arbitrary initial value, but objects 
defined with this TC are required to start at the value 
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zero. This behavior is not likely to have any adverse 
effects on management applications which are expecting 
Counter64 semantics. 


This textual convention represents a limited and short-term 
solution, and may be deprecated as a long term solution is 
defined and deployed to replace it." 

SYNTAX Counter64 


END 


5. Intellectual Property 


The IETF takes no position regarding the validity or scope of any 
intellectual property or other rights that might be claimed to 
pertain to the implementation or use of the technology described in 
this document or the extent to which any license under such rights 
might or might not be available; neither does it represent that it 
has made any effort to identify any such rights. Information on the 
IETF’s procedures with respect to rights in standards-track and 
standards- related documentation can be found in BCP-11. Copies of 
claims of rights made available for publication and any assurances of 
licenses to be made available, or the result of an attempt made to 
obtain a general license or permission for the use of such 
proprietary rights by implementors or users of this specification can 
be obtained from the IETF Secretariat. 


The IETF invites any interested party to bring to its attention any 
copyrights, patents or patent applications, or other proprietary 
rights which may cover technology that may be required to practice 
this standard. Please address the information to the IETF Executive 
Director. 
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9. Full Copyright Statement 
Copyright (C) The Internet Society (2000). All Rights Reserved. 


This document and translations of it may be copied and furnished to 
others, and derivative works that comment on or otherwise explain it 
or assist in its implementation may be prepared, copied, published 
and distributed, in whole or in part, without restriction of any 
kind, provided that the above copyright notice and this paragraph are 
included on all such copies and derivative works. However, this 
document itself may not be modified in any way, such as by removing 
the copyright notice or references to the Internet Society or other 
Internet organizations, except as needed for the purpose of 
developing Internet standards in which case the procedures for 
copyrights defined in the Internet Standards process must be 
followed, or as required to translate it into languages other than 
English. 


The limited permissions granted above are perpetual and will not be 
revoked by the Internet Society or its successors or assigns. 


This document and the information contained herein is provided on an 
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 


Acknowledgement 


Funding for the RFC Editor function is currently provided by the 
Internet Society. 


Bierman, et al. Standards Track [Page 10] 


